Any transmission medium or network requires a finite time to carry a message from source to destination. The speed of light over a direct path determines the theoretical minimum transmission time. Also, all transmission equipment introduce additional delay, called latency. For example, although satellite networks have advantages such as permitting telecommunication across any distance without laying ground lines, the distance between the ground and the satellite introduces significant transmission delay. As another example, cellular wireless networks contain many packet switches, each of which introduces some latency; the cumulative delay can exceed that of a satellite link. Intercontinental terrestrial networks for packet data also display larger than desired latency.
Consider first the issue of latency generated within satellite networks. Most satellite networks have the following components: a hub (i.e., the main ground station), one or more satellites, and remote ground stations. Any location may be referred to as a “node.” Geosynchronous-orbit satellites (i.e., satellites that maintain the same position above a geographic point on the earth's surface) orbit at about 22,300 miles (about 35,900 km) above the earth's surface. At each ground node, communications are facilitated by a satellite modem which formats data for upward transmission to a satellite, and receives down transmissions of information at any location that has a satellite dish.
As a result of the distance traveled by transmissions from one node (e.g., a ground station) to another node via a satellite, significant transmission delays may be incurred. That is, satellite networks have inherent round-trip delay characteristics of about ½ second for a typical geo-stationary satellite circuit. Such delay causes certain performance issues for voice applications. For example, problems such as “conversation collisions” occur wherein both parties start talking at the same time because neither can hear that the other party is also talking. Data protocols within satellite and other high-latency networks also face problems with long delays. Two problems in particular handicap the use of satellite networks for data applications: throughput limitation and partial security.
Throughput limitation refers to the fact that Transmission Control Protocol (TCP) sending devices (among many devices that transmit data packets) cannot transmit at rates in excess of the rates at which the receiver device can acknowledge receipt of the packets. In essence, satellite latency effectively caps standard TCP throughput per session, regardless of the bandwidth available.
In general network data communications, data packets are transmitted with accompanying control headers. The TCP header follows the Internet Protocol (IP) header. Higher layer protocols ride on TCP (that is, their headers follow the TCP header in the IP packet). In general, most protocols that desire guaranteed delivery rely on TCP; such protocols include HTTP, telnet, and FTP.
TCP was designed for error detection, error correction via retransmission, and congestion avoidance and recovery via a flow control mechanism that reduces throughput over high-latency networks. TCP is the connection-oriented transport protocol that operates end-to-end to ensure accurate delivery of data. This is in contrast with IP, the connectionless network protocol, which simply delivers packets, or datagrams, on a best-effort basis.
With reference to FIG. 1, a standard TCP data packet 101 is shown with relevant fields. The data packet 101 includes IP header 110, TCP header 120 and a data payload 130. Details pertaining to IP header 110 may be found in Request for Comment published by the Interact Engineering Task Force (“RFC”) 791 (Internet Protocol); details pertaining to TCP header 120 may be found in RFC793 (TCP). The data payload 130 may contain additional higher layer application headers, such as HTTP, telnet and FTP header information. The TCP header 120 further includes various control fields. When a connection is established between two TCP devices, messages are exchanged between the TCP devices to synchronize the connection and establish a window size for data payload 130. Window sizes are exchanged in the Window field 122, and indicate a total amount of data that may be transmitted before a receiving TCP device must confirm the reception of the data via the Acknowledgement (ACK) field 124. An additional field of interest is the TCP Options field 126.
An advantage of using a TCP acknowledgement system is that by controlling the window size through adjustments of the Window field 122, each side of a TCP connection may control the rate at which it receives data. However, in a satellite network, the inherent delay caused by long-distance transmission results in each sending TCP device being required to wait idle for each acknowledgement. In practice, this forced wait limits the average transmission speed to approximately 130 kbit/s, regardless of the channel bandwidth of the satellite transmission. An additional problem is that a TCP device may misinterpret the inherently long delay as network congestion. As a result, transmission rates are automatically reduced through a modification algorithm which reduces the Window field 122 in the data packets sent. This algorithm implemented by TCP further reduces the efficiency of a channel impaired by high latency.
A second drawback in using satellite communication is low security. Transmissions from satellites are available to anyone with a suitable receiver. To deter interception, service providers routinely encrypt transmissions between satellite modems. However, hub earth stations are seldom at customer sites and so there will likely exist a terrestrial segment that is not protected by the satellite service provider. As a result, endpoint users of the transmission must create their own security or encryption.
Prior art solutions for each problem (i.e., throughput limitation and low security) do exist, but each have their own respective drawbacks.
One solution to the throughput limitation is shown in FIG. 2. FIG. 2 depicts a satellite communication system 201 that includes multiple TCP accelerators 220 and 221, such as performance enhancing proxies or PEP devices. PEP functionality can be built into a server or an RFC modem or other appropriate processor. A PEP device may be used to improve the performance of transmission protocols on networks where performance suffers due to the characteristics of the network (long delay and low channel reliability in satellites). In the satellite communication system 201, a source port 210 may establish a communication session with a destination port 215. TCP data packets are sent from the source port 210 to the destination port 215 via a satellite network 240. Satellite modems 230 and 231 act as terrestrial nodes for the satellite transmission. In this solution, a data packet sent from source port 210 will be intercepted by TCP accelerator 220. The TCP accelerator 220 then “spoofs” the protocol (for example, TCP) used by the endpoint. In other words, the TCP accelerator 220 acts as if it is the destination port 215, and itself sends ACK packets to the source port 210. The original data packet (with modified TCP header or with field values appropriate for the destination port 215) is then sent via the satellite network 240 to the TCP accelerator 221, from where it is reconverted into its original form and forwarded to the destination port 215. Because the idle periods incurred by waiting for an ACK signal are hereby minimized by the spoof, the use of TCP accelerators 220 and 221 allows standard protocols to deliver higher throughput through satellite network 240.
An important consideration when using the TCP accelerators 220 and 221 is that the two TCP accelerators 220 and 221 coordinate the TCP header fields to prevent the end points (i.e., the source port 210 and the destination port 215) from detecting the presence of the TCP accelerators 220 and 221 in the satellite (or other high-latency) connection. To accomplish this, this method must break the connection into three segments. The segment between the source port 210 and the TCP accelerator 220 will carry normal TCP sessions 280, i.e., communications involving data packets described by IP and TCP headers originating from the source port 210 and targeting the destination port 215. Similarly, the segment between the TCP accelerator 221 and the destination port 215 will also carry normal TCP sessions 280 (i.e., the IP and TCP headers will identify the source port 210 and the destination port 215). The segment between the two TCP accelerators 220 and 221 will carry modified or spoofed TCP sessions 285. The total circuit avoids the throughput limit by avoiding the limiting behavior of TCP over the high-latency segment carrying the spoofed TCP sessions 285.
There are several advantages of using TCP accelerators, such as PEPs. A proxy on the ground deals with its adjacent end point using standard TCP, so the customer device needs no modification. Prompt ACKs from the PEP give the sender permission to send more, even before the previous window of data reaches the far-end earth station. The customer can always send transmissions at the rate available on the LAN/WAN or other high-latency network, up to the capacity of the high-latency network. At the receiving end, the PEP appears to be a normal router. Over the satellite network, proxies take full advantage of the available bandwidth to achieve maximum throughput. PEPs may work with a larger TCP window, with a protocol that does not use windows and acknowledgments (e.g., User Data Protocol (UDP)), or any other mechanism.
However, the advantages of using TCP accelerators are minimized by the use of existing solutions to the partial security problem inherent to any satellite transmission. The partial security drawback of using satellite transmissions is often solved using virtual private networks, or VPNs. VPNs based on the widely-used IPsec (“IP Secure”) protocol provide the most secure transmission generally available from endpoint to endpoint on IP networks. Only the VPN endpoints can decrypt the information. IPsec comes in two formats—Encapsulating Security Payload (ESP) and Authentication Header (AH).
FIG. 3 summarizes the two IPsec formats. In FIG. 3, an unprotected data packet 310 contains an IP header 312, a TCP header 314 and a data payload 316. When IPsec ESP is applied, the entire data packet 310 is encrypted (the IP header 312, the TCP header 314 and the data payload 316). The resulting encrypted data packet 320 contains a new modified IP header 321, an IPsec ESP header 322, and then an encrypted region 324 that includes the IP header 312, TCP header 314 and the data payload 316. An ESP trailer 326 is also inserted. This total encryption, however prevents the PEP device from seeing or modifying the original TCP header 314 (specifically, the ACK and Window fields of the header), so these sessions cannot be accelerated by PEP devices. On the other hand, a data packet protected by the IPsec AH format does not encrypt the payload and instead leaves the TCP header visible. An AH protected data packet 330 includes a new modified 331, an IPsec AH header 332, the original IP header 312, the original TCP header 314 and the data payload 316. The IP header 312, the TCP header 314 and the data payload 316 are in an authentication-protected region 334 established by the authentication algorithms of the IPsec AH header 332. Any change in the protected TCP header (like those changes made by PEP devices) will result in a failure of the authentication process and a rejection of the protected packet. This also prevents acceleration by PEP.
A solution to the combined problem has been to allow PEPs to encrypt and decrypt data at the site of the PEP device. The result is that a PEP device that has just decrypted data will send unencrypted data to an IPsec router. Even though the IPsec router may be proximate to the PEP device, the existence of an “unencrypted six inches” on the cable between an IPsec router and a PEP is unacceptable to many enterprises and government agencies as they often require complete end-to-end confidentiality.
The result of these problems has been a conflict between maximizing throughput and maximizing high security using IPsec VPNs. In summary, standard IPsec cannot be accelerated by PEP devices; the additional processing time to encrypt/decrypt (and compress/decompress) further lengthens the ACK cycle, cutting throughput and reducing security.
Accordingly, there exists a significant need for a full secure network that provides high performance transmission.